In any enterprise, data regarding aspects thereof is accumulated over time. This data can be used to report the status of the enterprise. For example, with regard to a sales enterprise, sales data can be accumulated pertaining to each sale of an item, including the salesman, the customer, the region of the salesman, the region of the customer, the amount of the sale, the quantity of the item sold, the date of the sale, the date of the delivery of the sold item, and so on. Based on such sales data, then, it may be that a report is generated that details sales by year, by month, by customer by year, by item by quarter, by salesman by delivery date, by region by week, etc.
The data that populates a report will typically be accumulated in a database. A database, as the term is used here, is a storehouse for digitally recorded data. To filter the data in a database into properly organized columns and rows for a report, a report designer may specify, in a report design, the particular data that is desired from a database. For example, a report designer might specify that he wants a “salesman name” in the first column of a report.
The report designer may then write a program that recognizes the field indicated for the first column of a report design (salesman name), queries a database for all salesman names, and places them one after the other in the first column of a report. Instead of writing his own program to carry out this task, the report designer may use commercial software that provides this function. Such software may allow a report designer to simply specify, in a report design, a type of data he wants in the first report column. The commercial software will then automatically analyze the report design, query a database, and place the desired data in the first column of a report. This operation is also available in commercial products for any number of columns and/or rows of a report.
An exemplary report design is illustrated in FIG. 2. The exemplary report design provides a salesman column 201, a 1990 sales column 202, and a total sales column 205. This report design may be submitted to supporting software that can pull the corresponding data from a database to populate the actual report. An example of what such an actual report may look like is provided in FIG. 3. FIG. 3 shows a populated salesman column 301, a populated 1990 sales data column 302, and a populated total sales column 305.
Exemplary report processing software for populating a report design with appropriate data is depicted in FIG. 5. The report processing software 510 may comprise a plurality of data extensions for properly interpreting the data stored in any of a plurality of data sources 520 and 521, which could be, e.g., databases. The report processing software may also comprise a number of rendering extensions 512 to properly output reports in an appropriate file format, e.g., Hyper-Text Markup Language (HTML) 530, Extensible Markup Language (XML) 531, or some other file format 532. A report design 500, also referred to herein as a report definition, is used by the report processing software to gather the data from data sources 520, 521 and compile the data into a properly structured report, outputting the report in any file format 530, 531, 532.
Different reports are designed for differing types and amounts of data. While some reports are quite simple, others present multiple types of data, and may show complex relationships between the data. For an example of a common data relationship, with reference to FIG. 1, a single field in a first column, e.g., Acme 101a, may be associated with a number fields in a second column, e.g., 102a, 102b, and 102c. To achieve this, report processing software must be able properly locate data in the various fields of a report. Bob's Discount 101b cannot appear in a cell immediately underneath Acme 101a; instead Bob's Discount 101b must be properly situated to visually correspond to the Bob's Discount data, e.g., 102d, 102e, 102f. Thus, report processing software must be populate reports in ways that are more intelligent than simply lumping data in columns and rows. This example is a small taste of the potential complexity in report design, the full scope of which will be appreciated by those of skill in the art. It should be emphasized here that while the look of an actual report may appear simple, techniques for supporting report design with commercial software is not necessarily simple, because of the variety of desired designs and the need to accurately populate reports that are designed in varying ways.
While report designers can always create customized computer programs to properly populate a particular report, many report designers do not have the expertise or the desire to write such custom programs. Furthermore, it may not be an effective use of a report designer's time to write such computer programs. Therefore, report designers are frequently called on to either make do with the available report designs provided by a commercial software product, or spend valuable time creating computer programs for a custom report design. Flexibility in report design is therefore a desirable attribute for commercial report design software. Simplicity is also a desirable attribute, as with all software, because users can more readily access features that are easily understandable.
Due to the above described situation, commercial software companies are called upon to provide report design software that accommodates as many varieties of report designs as can practically be accommodated. This can be a difficult task. If done well, the task involves providing an easily understandable technique for specifying a report design that is both flexible and highly accurate in allowing designers to convey the content and layout of data for a report. Traditionally, this task has been resolved by providing two broad options for report design: the table and the matrix.
The following brief discussion in connection with FIG. 1 and FIG. 4 will point out some of the advantages and limitations of the traditional table report design and matrix report design. First, FIG. 1 shows some typical features of a report that can be generated using a table design. As suggested by FIG. 1, a table design allows report designers to use only fixed columns. These are referred to as static columns 104. In other words, a report designer using the table design can specify a column for customer 101, year 102, sales 103 and so on, as desired, to contain the all desired data for a report.
In contrast, the rows of a table can be dynamic. For example, refer to dynamic rows 105. These rows 105 can be expanded as necessary to adequately present greater or lesser amounts of report data. For example, with reference to dynamic rows 105: as time goes on, the years reported 102a and 102b may be expanded to also report the years 2003 and 2004. Additional rows can be added to provide all corresponding data for these rows in the report. This allows report designers to re-use a single report design from year to year, or to present data of varying scope using the same report design.
A table report design may also include header and footer rows. In FIG. 1, the top row specifying column names, e.g., customer 101, year 102, and sales 103, is a header row. The bottom row, specifying a grand total 101c of sales, is a footer row. Each of the header and footer rows contain cells with data of different types than the non-header/footer rows, and typically summarizes the data in those rows.
A table report design can further contain nested groups, each with a header and footer row. FIG. 1 illustrates this feature by giving nested header and footer rows for both customers 101a and 101b. The row with only Acme 101a and the row with only Bob's Discount 101b are both header rows. The two rows containing subtotals 102c and 102f are footer rows. Again, each of these nested header and footer rows 101a, 101b, 102c, 102f contain information that is different from the non-header/footer rows.
Finally, a table report design can specify detail rows within an innermost group. This aspect of a table design is not represented in the actual table of FIG. 1. An example of such a detail row is, e.g., if additional data is desired about 2001 sales 103a for Acme, a detail row could be specified in a report design that inserts additional information in a row beneath the row indicating 2001 sales 103a for Acme.
In summary, report designers using a table design in accordance with the present state of the art can specify fixed, or static, columns, along with either static or dynamic rows. Any number of header and footer rows are also available. The software that processes the report design will then place all specified data in the appropriate columns and rows. For dynamic rows as many rows as necessary may be generated to accommodate data.
The other design option available to report designers in conjunction with commercially available report-generation software is the matrix. An exemplary matrix that exposes the features of such a design is provided in FIG. 4. As can be surmised from the actual report of FIG. 4, the report design for a matrix allows dynamic columns 450. The columns containing yearly sales data for 2001 (401) and 2001 (402) that can be supplemented as necessary for additional years. For example, if data is available for 2003 and 2004, such data can be automatically added to the report, without the need to specify additional columns for these years in the report design. Each column group in a matrix can contain a header 430 and a footer 430. Note, however, that the dynamic columns of a matrix, while providing an advantage over the table design, do not give as much flexibility as could be desired in report design. For example, using current commercial report design software, dynamic columns 450 cannot contain nested dynamic columns. While a custom program could be written to accomplish this on a case-by case basis, generating such a custom program presents a formidable hurdle for a report designer.
A matrix report design also permits both static and dynamic rows, e.g., 470 and 460, respectively. In FIG. 4, a header 440 is provided for column names, e.g., 2001 (401), 2002 (402) and total (403). The row groups corresponding to the retail and wholesale sections are not provided with row headers and footers, although they could be. A footer row 470 is provided for grand total 422 data. Elements 404 and 423 are instances of a dynamic row group 460. In this regard, one or more rows in a matrix can be specified as a dynamic row in a report design. When combined with data, such a dynamic row can be expanded to accommodate available data. In the example of FIG. 4, the available data apparently contained retail 404 and wholesale 413 data. However, note that dynamic rows 460 contain only static nested rows 461. The present state of the art is incapable of accommodating dynamic nested rows in a matrix report design. Moreover, the state of the art does not allow any number of further combinations of static and dynamic rows that may be desired in report designs.
In summary, a matrix allows for presentation of report data with a number of fixed rows or simple dynamic rows that can be further delineated by row headers and footers. Static or dynamic columns can be used to display data, as necessary. The dynamic columns/rows may also be further delineated by header and footer columns to provide additional related information in a report.
The table and matrix report design therefore each provide some useful features, but are limited in the ways they allow report designers to specify the features of a report. A more flexible format for report designs that is at the same time simple to understand will help to improve reports by permitting a broader range of designs that can be easily implemented via standardized commercial software that does not require customized additions to properly present the data of a report.
In light of the current state of the industry in support for report designs, there is a heretofore unrecognized need to provide additional flexibility and simplicity in supporting the various report designs that may be desired for the presentation of data.